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S/MIME Capabilities for Public Key Definitions 
Abstract 


This document defines a set of Secure/Multipurpose Internet Mail 
Extensions (S/MIME) Capability types for ASN.1 encoding for the 
current set of public keys defined by the PKIX working group. This 
facilitates the ability for a requester to specify information on the 
public keys and signature algorithms to be used in responses. 

"Online Certificate Status Protocol Algorithm Agility" (RFC 6277) 
details an example of where this is used. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6664. 


Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


In the process of dealing with the Online Certificate Status Protocol 
(OCSP) agility issues in [RFC6277], it was noted that we really 
wanted to describe information to be used in selecting a public key, 
but we did not have any way of doing so. This document fills that 
hole by defining a set of Secure/Multipurpose Internet Mail 
Extensions (S/MIME) Capability types for a small set of public key 
representations. 


S/MIME capabilities were originally defined in [SMIMEv3-MSG] as a way 
for the sender of an S/MIME message to tell the recipient of the 
message the set of encryption algorithms that were supported by the 
sender’s system. In the beginning, the focus was primarily on 
communicating the set of encryption algorithms that were supported by 
the sender. Over time, it was expanded to allow for an S/MIME client 
to state that it supported new features such as the compression data 
type and binary encoded contents. The structure was defined so that 
parameters can be passed in as part of the capability to allow for 
subsets of algorithms to be used. This was used for the RC2 
encryption algorithm, although only two values out of the set of 
values were ever used. The goal of restricting the set of values is 
to allow a client to use a simple binary comparison in order to check 
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for equality. The client should never need to decode the capability 

and do an element-by-element comparison. Historically, this has not 

been a problem as the vast majority of S/MIME capabilities consist of 
just the algorithm identifier for the algorithm. 


Many people are under the impression that only a single data 
structure can be assigned to an object identifier, but this is not 
the case. As an example, the OID rsaEncryption is used in multiple 
locations for different data. It represents a public key, a key 
transport algorithm (in S/MIME), and was originally used in the 
Public-Key Cryptography Standards (PKCS) #7 specification as a 
signature value identifier (this has since been changed by the S/MIME 
specifications). One of the implications is that when mapping an 
object identifier to a data type structure, the location in the ASN.1 
structure needs to be taken into consideration as well. 


1.1. ASN.1 Notation 


The main body of the text is written using snippets of ASN.1 that are 
extracted from the ASN.1 2008 module in Appendix A. ASN.1 2008 is 
used in this document because it directly represents the metadata 
that is not representable in the 1988 version of ASN.1 but instead is 
part of the text. In keeping with the current policy of the PKIX 
working group, the 1988 module along with the text is the normative 
module. In the event of a conflict between the content of the two 
modules, the 1988 module is authoritative. 


When reading this document, it is assumed that you will have a degree 
of familiarity with the basic object module that is presented in 
Section 3 of RFC 5912 [RFC5912]. We use the SMIME-CAPS object in 
this document; it associates two fields together in a single object. 


SMIME-CAPS ::= CLASS { 
&id OBJECT IDENTIFIER UNIQUE, 
&Type OPTIONAL 


} 
WITH SYNTAX { [TYPE &Type] IDENTIFIED BY &id } 


These fields are: 


&id contains an object identifier. When placed in an object set, 
this element is tagged so that no two elements can be placed in 
the set that have the same value in the &id field. Note that this 
is not a restriction saying that only a single object can exist 
with a single object identifier. 
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&éType optionally contains an ASN.1 type identifier. If the field 
&Type is not defined, then the optional parameters field of the 
AlgorithmIdentifier type would be omitted. 


The class also has a specialized syntax for how to define an object 
in this class. The all uppercase words TYPE IDENTIFIER and BY are 
syntactic sugar to make it easier to read. The square brackets 
define optional pieces of the syntax. 


The ASN.1 syntax permits any field in an object to be referenced in 
another location. This means that if an object called foo has a 
field named &value, the value can be directly referenced as foo.& 
value. This means that any updates to values or types are 
automatically propagated, and we do not need to replicate the data. 


1.2. Requirements Terminology 


When capitalized, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


2. RSA Public Keys 


There are currently three different public key object identifiers for 
RSA public keys. These are RSA, RSA Encryption Scheme - Optimal 
Asymmetric Encryption Padding (RSAES-OAEP), and RSA Signature Scheme 
with Appendix - Probabilistic Signature Scheme (RSASSA-PSS) . 


2.1. Generic RSA Public Keys 


Almost all RSA keys that are contained in certificates today use the 
generic RSA public key format and identifier. This allows for the 
public key to be used both for key transport and for signature 
validation (assuming it is compatible with the bits in the key usage 
extension). The only reason for using one of the more specific 
public key identifiers is if the user wants to restrict the usage of 
the RSA public key to a specific algorithm. 


For the generic RSA public key, the S/MIME capability that is 
advertised is a request for a specific key size to be used. This 
would normally be used for dealing with a request on the key to be 
used for a signature that the client would then verify. In general, 
the user would provide a specific key when a key transport algorithm 
is being considered. 
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The ASN.1 that is used for the generic RSA public key is defined as 
below: 


scap-pk-rsa SMIME-CAPS ::= { 
TYPE RSAKeyCapabilities 
IDENTIFIED BY pk-rsa.&id 

} 


RSAKeyCapabilities ::= SEQUENCE { 
minKeySize RSAKeySize, 
maxKeySize RSAKeySize OPTIONAL 
} 
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 | 


8192 | 15360, ...) 


In the above ASN.1, we have defined the following: 


scap-pk-rsa is a new SMIME-CAPS object. This object associates the 
existing object identifier (rsaEncryption) used for the public key 
in certificates (defined in [RFC3279] and [RFC5912]) with a new 
type defined in this document. 


RSAKeyCapabilities carries the set of desired capabilities for an 
RSA key. The fields of this type are: 


minKeySize contains the minimum length of the RSA modulus to be 
used. This field SHOULD NOT contain a value less than 1024. 


maxKeySize contains the maximum length of the RSA modules that 
should be used. If this field is absent, then no maximum 
length is requested/expected. This value is normally selected 
so as not to cause the current code to run unacceptably long 
when processing signatures. 


RSAKeySize provides a set of suggested values to be used. The 
values 1024, 2048, 3072, 7680, and 15360 are from the NIST guide 
on signature sizes [NIST-SIZES] while the others are common powers 
of two that are used. The list is not closed, and other values 
can be used. 


2.2. RSASSA-PSS Signature Public Keys 
While one will use the generic RSA public key identifier ina 
certificate most of the time, the RSASSA-PSS identifier can be used 


if the owner of the key desires to restrict the usage of the key to 
just this algorithm. This algorithm does have the ability to place a 
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set of algorithm parameters in the public key info structure, but 
they have not been included in this location as the same information 
should be carried in the signature S/MIME capabilities instead. 


The ASN.1 that is used for the RSASSA-PSS public key is defined 
below: 


scap-pk-rsaSSA-PSS SMIME-CAPS ::= { 
TYPE RSAKeyCapabilities 
IDENTIFIED BY pk-rsaSSA-PSS.&id 

} 


In the above ASN.1, we have defined the following: 


scap-pk-rsaSSA-PSS is a new SMIME-CAPS object. This object 
associates the existing object identifier (id-RSASSA-PSS) used for 
the public key certificates (defined in [RFC4055] and [RFC5912]) 
with type RSAKeyCapabilities. 


2.3.  RSAES-OAEP Key Transport Public Keys 


While one will use the generic RSA public key identifier ina 
certificate most of the time, the RSAES-OAEP identifier can be used 
if the owner of the key desires to restrict the usage of the key to 
just this algorithm. This algorithm does have the ability to place a 
set of algorithm parameters in the public key info structure, but 
they have not been included in this location as the same information 
should be carried in the key transport S/MIME capabilities instead. 


The ASN.1 that is used for the RSAES-OAEP public key is defined 
below: 


scap-pk-rsaES-OAEP SMIME-CAPS ::= { 
TYPE RSAKeyCapabilities 
IDENTIFIED BY pk-rsaES-—OAEP.&id 


} 

In the above ASN.1, we have defined the following: 

scap-pk-rsaES-OAEP is a new SMIME-CAPS object. This object 
associates the existing object identifier (id-RSAES-OAEP) used for 


the public key certificates (defined in [RFC4055] and [RFC5912]) 
with type RSAKeyCapabilities. 
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3. Diffie-Hellman Keys 


There are currently two Diffie-Hellman (DH) public key object 


identifiers. These are DH key agreement and Digital Signature 
Standard (DSA). 


3.1. DSA Signature Public Key 


This public key type is used for the validation of DSA signatures. 
The ASN.1 that is used for DSA keys is defined below: 


scap-pk-dsa SMIME-CAPS ::= { 
TYPE DSAKeyCapabilities 
IDENTIFIED BY pk-dsa.&id 

} 


DSAKeyCapabilities ::= CHOICE { 
keySizes [0] SEQUENCE { 
minKeySize DSAKeySize, 
maxKeySize DSAKeySize OPTIONAL, 
maxSizeP [1] INTEGER OPTIONAL, 
maxSizeQ [2] INTEGER OPTIONAL, 
maxSizeG [3] INTEGER OPTIONAL 
}, 
keyParams [1] pk-dsa.&Params 
} 
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 ) 


In the above ASN.1, we have defined the following: 


scap-pk-dsa is a new SMIME-CAPS object. This object associates the 
existing object identifier (id-dsa) used for the public key in 
certificates (defined in [RFC3279] and [RFC5912]) with a new type 

defined here, DSAKeyCapabilities. 

DSAKeyCapabilities carries the desired set of capabilities for the 
DSA key. The fields of this type are: 


keySizes is used when only a key size is needed to be specified 
and not a specific group. It is expected that this would be 
the most commonly used of the two options. In key sizes, the 
fields are used as follows: 


minKeySize contains the minimum length of the DSA modulus to 
be used. 
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maxKeySize contains the maximum length of the DSA modules that 
should be used. If this field is absent, then no maximum 
length is requested/expected. 


maxSizeP contains the maximum length of the value p that 
should be used. If this field is absent, then no maximum 
length is imposed. 


maxSizeQ contains the maximum length of the value q that 
should be used. If this field is absent, then no maximum 
length is imposed. 


maxSizeG contains the maximum length of the value g that 
should be used. If this field is absent, then no maximum 
length is imposed. 


keyParams contains the exact set of DSA for the key used to sign 
the message. This field is provided for completeness and to 
match the fields for Elliptic Curve; however, it is expected 
that usage of this field will be extremely rare. 


3.2. DH Key Agreement Keys 
This public key type is used with the DH key agreement algorithm. 
The ASN.1 that is used for DH keys is defined below: 
scap-pk-dh SMIME-CAPS ::= { 
TYPE DSAKeyCapabilities 
IDENTIFIED BY pk-dh.&id 
} 
In the above ASN.1, we have defined the following: 
scap-pk-dh is a new SMIME-CAPS object. This object associates the 
existing object identifier (dhpublicnumber) used for the public 
key algorithm in the certificates (defined in [RFC3279] and 
[RFC5912]) with a new type defined above, DSAKeyCapabilities. 
4. Elliptic Curve Keys 
There are currently three Elliptic Curve Cryptography (ECC) public 


key object identifiers. These are EC, EC-DH, and Elliptic Curve 
Menezes-Qu-Vanstone (EC-MQV). 
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4.1. Generic Elliptic Curve Keys 


Almost all ECC keys that are contained in certificates today use the 
generic ECC public key format and identifier. This allows for the 
public key to be used both for key agreement and for signature 
validation (assuming the appropriate bits are in the certificate). 
The only reason for using one of the more specific public key 
identifier is if the user wants to restrict the usage of the ECC 
public key to a specific algorithm. 


For the generic ECC public key, the S/MIME capability that is 
advertised is a request for a specific group to be used. 


The ASN.1 that is used for the generic ECC public key is defined 
below: 


scap-pk-ec SMIME-CAPS ::= { 
TYPE EC-SMimeCaps 
IDENTIFIED BY pk-ec.&id 
} 


EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters 


In the above ASN.1, we have defined the following: 


scap-pk-ec is a new SMIME-CAPS object. This object associates the 
existing object identifier (id-ecPublicKey) used for the public 
key algorithm in the certificates (defined in [RFC5480] and 
[RFC5912]) with the new type EC-SMimeCaps. 


EC-SMimeCaps carries a sequence of at least one ECParameters 
structure. This allows for multiple curves to be requested in a 
single capability request. A maximum/minimum style of specifying 
sizes is not provided as much greater care is required in 
selecting a specific curve than is needed to create the parameters 
for a DSA/DH key. As specified in [RFC5480], for PKIX-compliant 
certificates, only the namedCurve choice of ECParameters is 
expected to be used. 
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4.2. Elliptic Curve DH Keys 


This public key type is used with the Elliptic Curve Diffie-Hellman 
key agreement algorithm. 


The ASN.1 that is used for EC-DH keys is defined below: 


scap-pk-ecDH SMIME-CAPS ::= { 
TYPE EC-SMimeCaps 
IDENTIFIED BY pk-ecDH.&id 

} 


In the above ASN.1, we have defined the following: 


scap-pk-ecDH is a new SMIME-CAPS object. This object associates the 
existing object identifier (id-ecDH) used for the public key 
algorithm in the certificate (defined in [RFC5480] and [RFC5912]) 
with the same type structure used for public keys. 


4.3. Elliptic Curve MQV Keys 


This public key type is used with the Elliptic Curve MOV key 
agreement algorithm. 


The ASN.1 that is used for EC-MQV keys is defined below: 


scap-pk-ecMQV SMIME-CAPS ::= { 
TYPE EC-SMimeCaps 
IDENTIFIED BY pk-ecMQV.é&id 

} 


In the above ASN.1, we have defined the following: 


scap-pk-ecMQV is a new SMIME-CAPS object. This object associates 
the existing object identifier (id-ecMQV) used for the public key 
algorithm in the certificate (defined in [RFC5480] and [RFC5912]) 
with the same type structure used for public keys. 


5. RSASSA-PSS Signature Algorithm Capability 


This document defines a new SMIMECapability for the RSASSA-PSS 
signature algorithm. One already exists in [RFC4055] where the 
parameters field is not used. 


When the S/MIME group defined an S/MIME capability for the RSASSA-PSS 
signature algorithm, it was done in the context of how S/MIME defines 
and uses S/MIME capabilities. When placed in an S/MIME message 
[SMIME-MSG] or in a certificate [RFC4262], it is always placed ina 
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sequence of capabilities. This means that one could place the 
identifier for RSASSA-PSS in the sequence along with the identifier 
for MD5, SHA-1, and SHA-256. The assumption was then made that one 
could compute the matrix of all answers, and the publisher would 
support all elements in the matrix. This has the possibility that 
the publisher could accidentally publish a point in the matrix that 
is not supported. 


In this situation, there is only a single item that is published. 
This means that we need to publish all of the associated information 
along with the identifier for the signature algorithm in a single 
entity. For this reason, we now define a new parameter type to be 
used as the SMIMECapability type, which contains a hash identifier 
and a mask identifier. The ASN.1 used for this is as follows: 


scap-sa-rsaSSA-PSS SMIME-CAPS ::= { 
TYPE RsaSsa-Pss-—sig-caps 
IDENTIFIED BY sa-rsaSSA-PSS.&id 
} 


RsaSsa-Pss-sig-caps ::= SEQUENCE { 
hashAlg SMIMECapability{{ MaskAlgorithmSet }}, 
maskAlg SMIMECapability{{ ... }} OPTIONAL, 


trailerField INTEGER DEFAULT 1 
} 


scap-mf-mgfl SMIME-CAPS ::= { 
TYPE SMIMECapability{{ ... }} 
IDENTIFIED BY id-mgf1l 


} 
MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgfl, ...} 

In the above ASN.1, we have defined the following: 

scap-sa-rsaSSA-PSS is a new SMIME-CAPS object. This object 
associates the existing object identifier (id-RSASSA-PSS) used for 


the signature algorithm (defined in [RFC4055] and [RFC5912]) with 
the new type RsaSsa-Pss-sig-caps. 


RsaSsa-Pss-sig-caps carries the desired set of capabilities for the 
RSASSA-PSS signature algorithm. The fields of this type are: 


hashAlg contains the S/MIME capability for the hash algorithm we 


are declaring we support with the RSASSA-PSS signature 
algorithm. 
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maskAlg contains the S/MIME capability for the mask algorithm we 
are declaring we support with the RSASSA-PSS signature 
algorithm. 


trailerField specifies which trailer field algorithm is being 
supported. This MUST be the value 1. 


NOTE: In at least one iteration of the design, we used a sequence of 
hash identifiers and a sequence of masking functions and again made 
the assumption that the entire matrix would be supported. This has 
been removed at this point since the original intent of S/MIME 
capabilities is that one should be able to do a binary comparison of 
the DER encoding of the field and determine a specific capability was 
published. We could return to using the sequence if we wanted to 
lose the ability to do a binary compare but needed to shorten the 
encodings. This does not currently appear to be an issue at this 
point. 


Security Considerations 


This document provides new fields that can be placed in an S/MIME 
capabilities sequence. There are number of considerations that need 
to be taken into account when doing this. 


As mentioned above, we have defined data structures to be associated 
with object identifiers in cases where an association already exists. 
When either encoding or decoding structures, care needs to be taken 
that the association used is one appropriate for the location in the 
surrounding ASN.1 structure. This means that one needs to make sure 
that only public keys are placed in public key locations, signatures 
are placed in signature locations, and S/MIME capabilities are placed 
in SMIMECapability locations. Failure to do so will create decode 
errors at best and can cause incorrect behavior at worst. 


The more specific the information that is provided in an S/MIME 
Capabilities field, the better the end results are going to be. 
Specifying a signature algorithm means that there are no questions 
for the receiver that the signature algorithm is supported. 
Signature algorithms can be implied by specifying both public key 
algorithms and hash algorithms together. If the list includes RSA 
v1.5, EC-DSA, SHA-1, and SHA-256, the implication is that all four 
values in the cross section are supported by the sender. If the 
sender does not support EC-DSA with SHA-1, this would lead to a 
situation where the recipient uses a signature algorithm that the 
sender does not support. Omitting SHA-1 from the list may lead to 
the problem where both entities support RSA v1.5 with SHA-1 as their 
only common algorithm, but this is no longer discoverable by the 
recipient. 
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7. 


7. 


7 


I} 


die 


As a general rule, providing more information about the algorithms 
that are supported is preferable. The more choices that are provided 
the recipient, the greater the likelihood that a common algorithm 
with good security can be used by both parties. However, one should 
avoid being exhaustive in providing the list of algorithms to the 
recipient. The greater the number of algorithms that are passed, the 
more difficult it is for a recipient to make intelligent decisions 
about which algorithm to use. This is a more significant problem 
when there are more than two entities involved in the "negotiation" 
of a common algorithm to be used (such as sending an encrypted S/MIME 
message where a common content encryption algorithm is needed). The 
larger the set of algorithms and the more recipients involved, the 
more memory and processing time will be needed in order to complete 
the decision-making process. 


The S/MIME capabilities are defined so that the order of algorithms 
in the sequence is meant to encode a preference order by the sender 
of the sequence. Many entities will ignore the order preference when 
making a decision either by using their own preferred order or using 
a random decision from a matrix. 
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Appendix A. 2008 ASN.1 Module 


This appendix contains a module compatible with the work done to 
update the PKIX ASN.1 modules to recent versions of the ASN.1 
specifications [RFC5912]. This appendix is to be considered 
informational per the current direction of the PKIX working group. 


PUBLIC-KEY-SMIME-CAPABILITIES 
{ iso(1) identified-organization(3) dod(6) internet (1) 
security(5) mechanisms(5) pkix(7) id-mod (0) 
id-mod-pubKeySMIMECaps-—08(78) } 
DEFINITIONS ::= 
BEGIN 
IMPORTS 
SMIME-CAPS, PUBLIC-KEY, SMIMECapability 
FROM AlgorithmInformation-2009 
{ iso(1) identified-organization(3) dod(6) internet (1) 
security(5) mechanisms(5) pkix(7) id-mod (0) 
id-mod-algorithmInformation—02 (58) } 


pk-rsa, pk-dsa, pk-dh, pk-ec, pk-ecDH, pk-ecMQV, ECParameters 
FROM PKIXAlgs-2009 
{ iso(1) identified-organization(3) dod(6) internet (1) 
security(5) mechanisms(5) pkix(7) id-mod (0) 
id-mod-pkixl-algorithms2008-02 (56) } 


pk-rsaSSA-PSS, pk-rsaES-OAEP, sa-rsaSSA-PSS, 
HashAlgorithms, id-mgf1 
FROM PKIX1-PSS-OAEP-Algorithms-—2009 
{ iso(1) identified-organization(3) dod(6) internet (1) 
security(5) mechanisms(5) pkix(7) id-mod (0) 
id-mod-pkix1l-rsa-pkalgs—02 (54) } 


-- Define a set containing all of the S/MIME capabilities defined 
-—- by this document. 


SMimeCaps SMIME-CAPS ::= { 
PubKeys-—SMimeCaps | 
scap-sa-rsaSSA-PSS 

} 


PubKeys-SMimeCaps SMIME-CAPS ::= { 
scap-pk-rsa scap-pk-rsaSSA-PSS | 
scap-pk-dsa 
scap-pk-ec | scap-pk-ecDH | scap-pk-ecMQV 


Schaad Informational [Page 15] 


RFC 6664 S/MIME Capabilities for Public Keys July 2012 


-- We defined RSA keys from the modules in RFC 3279 and RFC 4055. 


scap-pk-rsa SMIME-CAPS ::= { 
TYPE RSAKeyCapabilities 
IDENTIFIED BY pk-rsa.&id 

} 


RSAKeyCapabilities ::= SEQUENCE { 
minKeySize RSAKeySize, 
maxKeySize RSAKeySize OPTIONAL 
} 
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 | 


8192 | 15360, ...) 


scap-pk-rsaES-OAEP SMIME-CAPS ::= { 
TYPE RSAKeyCapabilities 
IDENTIFIED BY pk-rsaES-OAEP.&id 

} 


scap-pk-rsaSSA-PSS SMIME-CAPS ::= { 
TYPE RSAKeyCapabilities 
IDENTIFIED BY pk-rsaSSA-PSS.&id 

} 


scap-sa-rsaSSA-PSS SMIME-CAPS ::= { 
TYPE RsaSsa-Pss-—sig-caps 
IDENTIFIED BY sa-rsaSSA-PSS.&id 
} 


RsaSsa-Pss-sig-caps ::= SEQUENCE { 
hashAlg SMIMECapability{{ MaskAlgorithmSet }}, 
maskAlg SMIMECapability{{ ... }} OPTIONAL, 


trailerField INTEGER DEFAULT 1 
} 


scap-mf-mgfl SMIME-CAPS ::= { 
TYPE SMIMECapability{{ ... }} 


IDENTIFIED BY id-mgf1l 
} 


MaskAlgorithmSet SMIME-CAPS ::= {scap-mf-mgfl, ...} 
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-- We define DH/DSA keys from the module in RFC 3279. 


scap-pk-dsa SMIME-CAPS ::= { 
TYPE DSAKeyCapabilities 
IDENTIFIED BY pk-dsa.&id 

} 


DSAKeyCapabilities ::= CHOICE { 
keySizes [0] SEQUENCE { 
minKkeySize DSAKeySize, 
maxKeySize DSAKeySize OPTIONAL, 
maxSizeP [1] INTEGER OPTIONAL, 
maxSizeQ [2] INTEGER OPTIONAL, 
maxSizeG [3] INTEGER OPTIONAL 
}, 
keyParams [1] pk-dsa.&Params 
} 
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 ) 
scap-pk-dh SMIME-CAPS ::= { 


TYPE DSAKeyCapabilities 
IDENTIFIED BY pk-dh.&id 


-- We define Elliptic Curve keys from the module in RFC 3279. 


scap-pk-ec SMIME-CAPS ::= { 
TYPE EC-SMimeCaps 
IDENTIFIED BY pk-ec.&id 
} 


EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters 


scap-pk-ecDH SMIME-CAPS ::= { 
TYPE EC-SMimeCaps 
IDENTIFIED BY pk-ecDH.&id 

} 


scap-pk-ecMQV SMIME-CAPS ::= { 
TYPE EC-SMimeCaps 
IDENTIFIED BY pk-ecMQV.éid 

} 
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END 
Appendix B. 1988 ASN.1 Module 
This appendix contains the normative ASN.1 module for this document. 


PUBLIC-KEY-SMIME-CAPABILITIES-88 
{ iso(1) identified-organization(3) dod(6) internet (1) 
security(5) mechanisms(5) pkix(7) id-mod (0) 
id-mod-pubKeySMIMECaps-—88(77) } 
DEFINITIONS ::= 
BEGIN 
IMPORTS 


ECParameters 
FROM PKIX1Algorithms2008 
{ iso(1) identified-organization(3) dod(6é) 
internet (1) security(5) mechanisms(5) pkix(7) id-mod(0) 
45 } 


id-mgf1 
FROM PKIX1—PSS-OAEP-Algorithms 
{ iso(1) identified-organization(3) dod(6é) 
internet (1) security(5) mechanisms(5) pkix(7) id-mod (0) 
id-mod-pkixl-rsa-pkalgs(33) } 


AlgorithmIdentifier 

FROM PKIX1Explicit88 
{ iso(1) identified-organization(3) dod(6) internet (1) 
security(5) mechanisms(5) pkix(7) id-mod (0) 
id-pkixl-explicit(18) } 


-- We define RSA keys from the modules in RFC 3279 and RFC 4055. 


RSAKeyCapabilities ::= SEQUENCE { 
minKkeySize RSAKeySize, 
maxKeySize RSAKeySize OPTIONAL 
} 
RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 4096 | 7680 | 


8192 | 15360, ...) 


RsaSsa-Pss-sig-caps ::= SEQUENCE { 
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hashAlg AlgorithmIdentifier, 
maskAlg AlgorithmIdentifier OPTIONAL, 
trailerField INTEGER DEFAULT 1 


-- We define DH/DSA keys from the module in RFC 3279. 


DSAKeyCapabilities ::= CHOICE { 
keySizes [0] SEQUENCE { 
minKeySize DSAKeySize, 
maxKeySize DSAKeySize OPTIONAL, 
maxSizeP [1] INTEGER OPTIONAL, 
maxSizeQ [2] INTEGER OPTIONAL, 
maxSizeG [3] INTEGER OPTIONAL 
}, 
keyParams [1] pk-dsa.&Params 
} 
DSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 ) 


-- We define Elliptic Curve keys from the module in RFC 3279. 


EC-SMimeCaps ::= SEQUENCE (SIZE (1..MAX)) OF ECParameters 

END 

Appendix C. Future Work 
A future revision of [RFC5912] should be done at some point to expand 
the definition of the PUBLIC-KEY class and allow for an 
SMIMECapability to be included in the class definition. This would 
encourage people to think about this as an issue when defining new 
public key structures in the future. 
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